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PREMIUM VOICE SERVICES 
FOR WIRELESS COMMUNICATIONS SYSTEMS 
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Serial Number 60/407,168, filed August 30, 2002, by Gorachand Kundu, Ravi 
5 Ayyasamy, and Krishnakant Patel, entitled DISPATCH SERVICE 
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BACKGROUND OF THE INVENTION 
10 1 . Field of the Invention. 

This invention relates in general to wireless communications systems, and 
more specifically, to a dispatch service providing premiimi voice services for wireless 
communications systems. 



15 2. Description of Related Art, 

Group-based voice services, such as two-way half-duplex voice calls within a 
group, also known as 'Tush-to-Talk," *Tress-to-Talk," PTT or P2T, have mormons 
revenue earnings potential for wireless networks, such as cellular networks and 
personal communications systems (PCS) networks. Corporate subscribers primarily 

20 use such services for coordinating field people or fleet users firom a central location. 

Currently, there are three major approaches employed in providing group- 
based voice services such as P2T in wireless networks. One approach requires the 
installation of a dedicated private network, parallel to the wireless network, to support 
the group-based voice services. NEXTEL uses such a system, based on a solution 

25 developed by MOTOROLA known as IDEN. However, a dedicated private network 
is costly to install and maintain and is employed by a few public wneless carriers. 
Also, the IDEN system is non-standard, and hence caimot be used in standard wireless 
communications networks, such as those based on CDMA and GSM. 
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Another approach is based on Voice over IP (VoIP) technologies. While this 
approach promises compliance with newer and emerging standards, such as GPRS 
(General Packet Radio Service), UMTS (Universal Mobile Telecommmiications 
System), etc., it does not provide a solution for carriers employing wireless networks 
5 based on existing standards, such as GSM (Global System for Mobile 

Communications), CDMA (Code Division Multiple Access), etc. However, even for 
the newer standards, solutions based on VoIP have serious drawbacks, including 
slower call setup, significant overhead, increased susceptibility to packet losses, low 
bit rate voice coders, and significant modifications to the mobile handset. There is a 

10 need, instead, for solutions that require only minimal upgrades to the handset. 

Still another approach is that defined in co-pending and commonly-assigned 
PCT utility patent application Serial Number PCT/US03/16386, filed on May 23, 
2003, by Gorachand Kundu, Ravi Ayyasamy, and Krishnakant Patel, entitled 
DISPATCH SERVICE ARCHITECTURE FRAMEWORK, attorneys' docket 

1 5 number 1 54.4-WO-Ul , which application is incorporated by reference herein. In this 
approach, group-based voice services are provided by a dispatch gateway that 
interfaces to the wireless network to provide the group-based voice services therein, 
wherein both the dispatch gateway and mobiles that use the group-based voice 
services communicate with each other using call setup and in-band signaling within 

20 the wireless network. 

Notwithstanding these innovations, there is a need in the art for advanced 
group-based voice services that comply with existiug and emerging wireless standards 
and provide superior user experiences. The present invention aims to satisfy this need 
by providing an architectural firamework for performing these advanced group-based 

25 voice services within wireless networks. 

SUMMARY OF THE INVENTION 
To overcome the limitations in tibie prior art described above, and to overcome 
other limitations that will become apparent upon reading and understanding the 
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present specification, the present invention discloses two advanced group-based voice 
services, known as Push-to-Conference (P2C) and Push-to-Message (P2M) services. 
The present invention also identifies a technique to achieve zero call-delay during call 
origination in Press-to-Talk services to enhance the user's experience, 

5 A real-time exchange (RTX) interfaces to the wireless network to provide a 

fiiU-duplex Push-to-Conference (P2C) session between an initiator and two or more 
other participants, wherein the P2C session comprises a full-duplex conference call, 
and both the real-time exchange and handsets participating in the P2C session 
communicate with each other using call setup and in-band signaling within the 

1 0 wireless network. 

The real-time exchange may be coupled to and work with a Push-to-Message 
(P2M) server to deUver multimedia messages in a non-real time manner from an 
origLoator to one or more recipients, without establishing voice paths, between the 
originator and recipients, wherein the P2M server, and an optional Voice Mail Server, 

1 5 provide a message storage facility for the multimedia messages. 

The handsets also permit zero-delay call setup. The user starts taUdng 
immediately upon initiation of call setup, wherein the user's speech is buffered by the 
handset. The buffered speech is then forwarded to the destination upon completion of 
the call setup. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 
Referring now to the drawings in which like reference numbers represent 
corresponding parts throughout: 

FIG. 1 is a block diagram that illustrates an exemplary embodiment of the 
25 dispatch services architecture firamework according to a preferred embodiment of the 
present invention; 

FIG. 2 illustrates a proposed architecture for the real-time exchange according 
to the preferred embodim^t of the present invention; 
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FIG. 3 is a diagram that illustrates the call flow for the user initiating a P2C 
session according to the preferred embodiment of the present invention; 

FIG. 4 is a diagram that illustrates the call flow for tiie user upgrading a P2T 
session to a P2C session according to the preferred CTabodiment of the present 
5 invention; 

FIG. 5 is a diagram that illustrates the call flow for the user receiving an 
upgrade of a P2T session to a P2C session according to the preferred embodiment of 
the present invention; 

FIG. 6 illustrates a system architecture for the P2M service according to the 
1 0 preferred embodiment of the present invention; 

FIG. 7 is a diagram that illustrates the call flow between a P2M server and a 
voice mail server according to the preferred embodiment of the present invention; 

FIG. 8 is a diagram that illustrates the call flow for the P2M Client sending a 
voice message using a Multi Media Services (MMS) protocol according to the 
1 5 preferred embodiment of the present invention; 

FIG. 9 is a diagram that illustrates the call flow for the P2M server processing 
a P2M message according to the preferred embodiment of tiie present invention; 

FIG. 10 is a diagram that illustrates the call flow for the P2M Server retrieving 
a P2M message according to the preferred embodiment of the present invention; 
20 FIG. 1 1 is a diagram that illustrates the call flow for the P2M Client deleting a 

P2M message according to the preferred embodiment of the present invention; 

FIG. 12 depicts the processing at the handset to implement zero delay call set- 
up according to the preferred embodiment of the present invention; 

FIG. 13 is a diagram that illustrates the call flow for a GSM P2T call 
25 according to a preferred embodiment of the present invention; and 

FIG. 14 is a diagram that illustrates the call flow for a CDMA P2T call 
according to a preferred embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 
In fhe following description of the preferred embodiment, reference is made to 
the accompanying drawings which form a part hereof, and in which is shown by way 
of illustration the specific embodiment in which the invention may be practiced. It is 
5 to be understood that other embodiments may be utilized as structural changes may be 
made without departing from the scope of the present invention. 

Overview 

The present invention provides two advanced group-based voice services, 
10 known as Push-to-Conference (P2C) and Push-to-Message 0P2M) services, in 
addition to Press-to-Talk (P2T) services. These services are provided by an 
architectural firamework that interfaces into the wireless network in order to provide 
group call setup and messaging. The present invention describes the architectural 
firamework in more detail below, and also shows the call flows for performing these 
1 5 advanced group-based voice services within the wireless network. 

Network Architecture 

FIG. 1 is a block diagram that illustrates an exemplary embodiment of a 
wireless communications network according to a preferred embodiment of the present 
20 invention. 

Within the network 100, an RTX ^eal-Time Exchange) 102, previously 
known as a Dispatch Gateway (DG), communicates with a MSG (Mobile Switching 
Center) 104 and PSTN (PubUc Switched Telephone Network) 106 using SS7 - 
ISUP/WIN/CAMEL (Signaling System 7 - Integrated Services Digital Network User 
25 Part/Wireless Intelligent Network/Customized AppUcations for Mobile Enhanced 
Logic) messages at a signaling plane 108. A bearer path 110 implements a TDM 
(Time Division Multiplexing) int^face carrying PCM (Pulse Code Modulation) or 
TFO (Tandem Free Operation) voice fiames. Support for TFO in this patii 1 10 is 
negotiated between a BSC (Base Station Controller) 1 12 and the RTX 102 for each 
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originating and tOTninating leg of a group call. The use of TFO ensures high voice 
quality (as voice codec conversion is avoided) between mobile-to-mobile calls. 

When a subscriber originates a group call, the MSG 104 routes the call to the 
RTX 102. The MSG 104 also requests the BSG 112 via 1 16 to estabUsh a radio traffic 

5 path 118 with the mobile handset 120 via the BTS (Base Transceiver Station) 122 (as 
it does for a normal cellular call). At this time, the BSC 112 tries to negotiate TFO (if 
it is supported) on a TDM link with the far end (in this case, the RTX 102). 

At the same time (after the MSG 104 terminates the group call request to the 
RTX 102), the RTX 102 identifies the terminating group users and their MS-ISDN 

10 (Mobile Station ISDN Number) numbers. It saids a ISUP call origination request for 
each terminating handset 120. It may send requests directly to the MSG 104, PSTN 
106 or BP network 124 via a PDSN ^bUc Data Switched Network) 126, Router 128, 
and/or Ihtemet/Intranet 130, depending on the routing table configuration for 
terminating MS-ISDN nimibers. Once the bearer path 1 10 is established, the RTX 102 

15 begins a negotiation with the far end (in this case, the terminating BSG 1 12) for each 
terminating leg to a handset 120. 

Once bearer paths 1 10 are established for originating and terminating legs for 
a group call, the RTX 102 switches (or duplicates) voice frames from the originating 
handset 120 to all terminating mobiles 120. 

20 The RTX 102 may use an IP network 124 or the Intemet/Intranet 130 for two 

different purposes. The IP network 124 or the Intemet/Intranet 130 can be used in a 
toll bypass mode where two RTXs 102 can exchange voice traffic bypassing the 
PSTN 106. However, each RTX 102 is responsible for terminating traffic to its closest 
MSG 104. In this case, the IP network 124 or the Intemet/Intranet 130 is used as a 

25 backbone transport of voice traf&c between two RTXs 102. 

The IP network 124 or the Intemet/Intranet 130 can also be used for a 
registration and presence application. Since the MSG 104 will not direct a registration 
request from a handset 120 to the RTX 102 (because it would require changes in the 
MSG 104), the latter does not have any information of the registered mobiles 120. To 
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circumvent this issue, a registration and presence ^plication runs over an IP stack in 
the handset 120. After the handset 120 registers for a data interface (i.e., obtaming an 
IP address) with the PDSN 126, the registration and presence application in the 
handset 120 registers with the RTX 102 using its IP address. The RTX 102 also uses 

5 this IP interface to update the presence information of other group mCTibers to a 

handset 120. There is also provision to use SMS (Short Message Service) transport to 
carry presence messages if an operator chooses to use SMS over a data channel. 

During roaming, a Home Location Register (HLR) 132 can be accessed via 
the MSG 104 and an IS-41 Imk 134. The HLR 132 can be used to track the presence 

10 of members of a group within the network and updates the mobiles 120 for those 
members with the network availability of other members of the group. This is 
described in more detail later in this document. 

Real Time Exchange 

15 FIG. 2 illustrates a proposed architecture for the RTX 102 according to the 

preferred embodiment of the present invention. 

The architecture includes a Call Processing system 200, Presence Server 202, 
Real-Time Event Processing system 204, one or more Media Managers 206, and an 
SMPP (Short Message Peer-to-Peer) Transport 208, as well as modules for various 

20 SS7 protocols, such as MTP-1 (Message Transfer Part Level 1) 210, MTP-2 (Message 
Transfer Part Level 2) 212, MTP-3 (Message Transfer Part Level 3) 214, ISUP 
(Integrated Services Digital Network User Part) 216, SCCP (Signaling Connection 
Control Part) 218, and TCAP (Transactions Capabilities Application Part) 220 
protocols. 

25 The Call Processing system 200, Presence Server 202, Media Managers 204, 

SMPP Transport 206, and other modules communicate across an IP network 222. The 
Real-Time Event Processing system 204 commxmicates directly with the Call 
Processing system 200, Presence Server 202, and the modules for various SS7 
protocols. The modules for various SS7 protocols communicate with other entities via 
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a SS7 Signaling Link 224. The SMPP Transport 206 conunimicates with a SMSC 
(Short Message Service Center) gateway using the SMPP protocol 226. The Media 
Managers 204 communicate among themselves using the H.1 10 protocol 228. 

The operation of these various components are described in more detail below. 

5 

Push-to-Conference (P20 

The RTX 102 interfaces to the wireless network 100 to provide support for a 
full-duplex Push-to-Conference (P2C) session between an initiator and two or more 
other participants, wherein the P2C session comprises a full-duplex conference call, 

10 and both the RTX 102 and handsets 120 participating in the P2C session 

communicate with each other using call setup and in-band signaling within the 
wireless network 100. In this context, the participants may comprise one or more 
contacts, one or more groups of contacts, or a subset of a group of contacts. 

The initiator may initiate the full-duplex P2C session by invoking *Tush-to- 

1 5 Conference" on their handset 120. Alternatively, the initiator may upgrade an 

established half-duples Push-to-Talk (PIT) session to the full-duplex P2C session by 
invoking 'TJpgrade to Conference" on their handset 120. 

In either instance, the initiator's handset 120 signals the RTX 102 via the 
wireless network 100, e.g., by transmitting one or more configured DTMF (Dual Tone 

20 Multi Frequency) digits to the RTX 102. The Media Manager systems 206 receive 
the DTMF digits and pass the DTMF digits to the Call Processing system 200. The 
Call Processing (CP) system 200 determines whether the initiator has subscribed to 
the P2C feature before initiating the full-duplex P2C session. Upon confirmation, the 
Call Processing system 200 initiates a new P2C session and, when upgrading a P2T 

25 session, suspends floor management for the P2T session. The Call Processing system 
200 interacts with the Presence Server 202 and Real-Time event Processing system 
204 to cause the wireless network 100 to perform call setup with the other participants 
for the full-duplex P2C session, and thereafter to manage the full-duplex P2C session. 
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For example, the initiator hears the "Conference Confirmation" or 
"Conference Upgrade" tone, if the initiator's request is accepted by the RTX 102 to 
initiate the full-duplex P2C session. On the other hand, the RTX 102 can reject the 
request, if the initiator has not subscribed with the network operator for the P2C 
5 service, wherein the RTX 102 transmits an error tone (e.g., ^^bong") to the initiator's 
handset 120. 

In another example, the other participants hear a "Join Conference" tone, if the 
initiator's request to initiate the full-duplex P2C session is accepted by the RTX 102, 
or the other participants hear a "Conference Upgrade" tone, if the initiator's request to 

10 upgrade the half-duplex P2T session to the full-duplex P2C session is accepted by the 
RTX 102. The other participants then invoke "Join Conference" on their handsets 120 
to join the fidl-duplex P2C session. Thereafter, the RTX 102 may respond wifli 
"Conference Confirmation" or "Conference Upgraded" tone as required. 

During the full-duplex P2C session, the Call Processing system 200 interacts 

1 S with the Media Manager systems 206 to maintain the H. 1 1 0 chaimels 227 and assign 
any additional H.1 10 chaimels 228 required for the P2C session, which may span 
across multiple Media Manager systems 206. During the full-duplex P2C session, the 
Media Manager systems 206 of the RTX 102 are used to mix audio streams from the 
initiator and other participants, and then deliver these mixed audio streams to the 

20 initiator and other participants, for full-duplex conference calling. The H. 1 10 channels 
228 are used for passing mixed and unmixed audio streams voice between the Media 
Manager systems 200 as required. 

Finally, the P2C session may be terminated in different ways. For example, 
the full-duplex P2C session may be terminated when the initiator disconnects the caU, 

25 even if the other participants do not disconnect. On the other hand, the full-duplex 
P2C session may continue when the initiator disconnects the call, if at least two of the 
other participants do not disconnect. These altematives are intended to be selectable 
by the network 100 operator and/or the user. 
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The system is designed to support the following features to accommodate user 
and network operator preferences: 

• In an established P2C session, the initiator and other participants can 
choose to remain silent by selecting a '*mute" option on their handset 

5 120, which will cause the handset 120 ndcrophone to be muted. The 

*'uiimute" option will allow the initiator and other participants to speak 
by unmuting the handset 120 microphone. 

• The initiator can add or drop participants during an active P2C session. 

• At any time during a full-duplex P2C session, the initiator can 
10 downgrade to a half-duplex P2T session. 

• The P2C session may be charged in different ways. For example, all 
charges related to flie full-duplex P2C session could be charged to the 
initiator. On the other hand, the initiator and other participants in the 
full-duplex P2C session could all be charged for their own usage 

15 during the P2C session. These alternatives are selectable by the 

network 100 operator and/or the user. 

• If the network 100 operator subscribes to the "Calling Party Pays" 
regime, where all charges related to a P2T session or a P2C session are 
charged to the calling party (initiator), then the P2C session is 

20 terminated when the initiator disconnects Hie call, even if the other 

participants do not disconnect. 

• If the network 100 operator subscribes to the "Called Party Pays" 
regime, where the initiator and other participants in a P2C call are each 
charged for their own usage, the P2C session continues, even if the 

25 initiator disconnects, so long as there are at least two participants on 

the P2C session. 

Generally, the facilities for the full-duplex P2C session or for upgrading the 
established half-duplex P2T session to the full-duplex P2C session are available to 
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users who have subscribed to this service. The user also must possess a handset 120 
with suitable modifications to allow menu interactions to service the P2C feature. 



P2C Call Flows 

5 The following sections describes the call flows for some of the major 

operations in tiie P2C service. 



User Initiates A P2C Session 

FIG. 3 is a diagram that illustrates the call flow for the user initiating a P2C 
10 session according to the preferred embodiment of the present invention. 

1. The user selects or creates a group on the handset 120. 

2. The RTX 102 returns one or more messages that show the cxirrent 
presence or availability for all group members, for all available networks. In a 
preferred embodiment, the current presence or availabiUty of all group members is 

1 5 visually displayed on the handset 120 within a few seconds of any state change, for all 
available networks. (An alert tone may also be used, as specified by the user.) 

3. The user presses the P2C button on the handset 120, and a 
corresponding message is transndtted to the RTX 102. 

4. The RTX returns one or more messages contaroing a "Conference 

20 Confirmation" tone, if the initiator's request to initiate the P2C session is accepted by 
the RTX 102, or an error tone, if the initiator's request to initiate the P2C session is 
denied by the RTX 102. 

5. During the P2C session, the user ^eaks into the handset 120 to talk, 
and a corresponding voice signal is transmitted to the RTX 102, for mixing with other 

25 audio and re-distribution to the other participants. 

6. During the P2C session, the user receives messages fix>m the RTX 102 
at the handset 120, wherein the messages include the mixed audio firom the 
participants distributed by the RTX 102. 

Further call processing is described in FIG. 4. 
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User Upgrades A P2T Session To A P2C Session 

FIG. 4 is a diagram that illustrates the call flow for the user upgrading a P2T 
session to a P2C session according to the preferred embodiment of the present 
5 invention. 

1. The user, who has already established a P2T session, presses the 
'Upgrade to P2C' button or menu item on the handset 120, and a corresponding 
message is transmitted to the RTX 102. 

2. The RTX retums one or more messages containing a "Conference 
10 Confirmation" tone, if the user's request to upgrade to a P2C session is accepted by 

the RTX 102, or an error tone, if the user's request to upgrade to a P2C session is 
denied by the RTX 102. 

3. During the P2C session, ttie user speaks into the handset 120 to talk, 
and a corresponding message is transn[iitted to the RTX 102, for mixing wifli other 

1 5 audio and re-distribution to the other participants. 

4. During the P2C session, the user receives messages from the RTX 102 
at the handset 120, wherein the messages include the mixed audio from the 
participants distributed by the RTX 102. 

Further call processing is described in FIG. 5. 

20 

User Receives An Upgrade Of A P2T Session To A P2C Session 

FIG. 5 is a diagram that illustrates the call flow for the user receiving an 

upgrade of a P2T session to a P2C session according to the preferred embodiment of 

the present invention. 
25 1 . During a P2T session, the RTX sends a message containing a 

"Conference Upgraded" tone to the handset 120. 

2. The user selects a "Join Conference" menu item on the handset 120. 

3. The RTX retums one or more messages containing a "Conference 
Confirmation" tone, if the user's request to join the P2C session is accepted by the 
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RTX 102, or an error tone, if the user's request to join the P2C session is denied by 
theRTX102. 

4. During the P2C session, the user ^eaks into the handset 120 to talk, 
and a corresponding message is transmitted to the RTX 102, for mixing with other 

5 audio and re-distribution to the other participants. 

5 . During the P2C session, the user receives messages from the RTX 1 02 
at the handset 120, wherein the messages include the mixed audio from the 
participants distributed by the RTX 102. 

10 Push-to-Message CP2M) 

This section describes the Press- to-Message (P2M) service using the MMS 
(Multi Media Services) protocol as the transport medium. The P2M service delivers 
multimedia messages (e.g., audio, video, images, data, etc.), known hereafter as P2M 
messages from an origmator to one or more recipients. 

15 FIG. 6 illustrates a sj^em architecture for the P2M service according to the 

preferred embodiment of the present invention. The system architecture includes one 
or more RTXs 102 coupled to a P2M server 600, which is (optionally) coupled to a 
Voice Mail Server 602, wherein the RTX 102 and the P2M servCT 600 work together 
to deliver P2M messages in a non-real time manner from an originator to one or more 

20 recipients, without establishing voice paths between the originator and recipients. 
Recipients may comprise one or more contacts, one or more groups of contacts, or a 
subset of a group of contacts. 

The P2M Server 600 provides a message storage facility for a user's P2M 
messages, and may interface to the Voice Mail Server 602 to provide a message 

25 storage facility for the multimedia messages, so that a user's message storage capacity 
is not limited to the capacity of their handset 120. The user can store P2M messages 
in the P2M Server 600, retrieve P2M messages from the P2M Server 600, and reply to 
the messages, or forward the messages to other P2M subscribers. The P2M service 
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supports the sending of P2M messages to one or more contacts, one or more groups of 
contacts, or a subset of a group of contacts. 

It is also possible to integrate any existing Voice Mail Server (VMS) with the 
P2M service. In such situations, the VMS can notify the P2M server 600 if any new 

S messages are waiting for a subscriber. 

MMS is used as the transport mechanism for conmiunicating the P2M 
messages between the handset 120 and P2M Server 600. The P2M Server 600 
interfaces to an SMSC (Short Message Service Center) 604, which conveys SMS 
messages to the MSG 104 and then to the handset 120, as well as the reverse. In some 

10 instances, it is also possible to use MMS or ff in place of SMS messaging. In 

addition, the P2M Server 600 interfaces to an MMSC (MMS Service Center) 606, 
which conveys MMS messages to a WAP (Wireless Application Protocol) Gateway 
608 and then to the handset 120, as well as the reverse. These messages received by 
the handset 120 are processed by a P2M Client 610 executed by the handset 120, 

1 5 which provides the necessary functionality for the P2M service. 

The major advantages of the P2M service include the following: 

• Users can transmit P2M messages in a non-real-time manner without 
needing to establish end-to-end voice pattis to the recipients. 

• Users can deliver P2M messages to a large number of recipients. 

20 • Users can schedule the delivery of P2M messages for a specific time. 

• The P2M Server 600 allows for the storage and retrieval of large P2M 
messages, thereby overcoming potential limitations in handset 120 
message storage capacity. 

o The P2M service does not require any changes to the wireless network 
25 elements. 

® Users can request a consolidated delivery receipt for any messages 
sent. 

A P2M subscriber wishing to send a P2M message selects a recipient (i.e., one 
or more contacts, one or more groups of contacts, or a subset of a group of contacts). 
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and records the P2M message. The P2M Client 610 in the handset 120 stores the 
recorded P2M message into a file in a predefined format. When the user finishes 
recording the P2M message, the P2M Client 210 forms an MMS message with the 
recipient's information (such as Group Id, Member Index, etc.), attaches flie file to the 
5 MMS message, and sends the MMS message to the P2M Server 600. 

The P2M Server 600 receives the MMS message firom the MMSC 606 over 
the MM7 interface. The P2M Server 600 performs authentication, extracts the 
recipient's information from the MMS message, and stores the P2M message in its 
temporary data 612. The P2M Server 600 then performs a remote query to one or 

10 more RTXs 102 to obtain the recipient's status and group member information. 

The P2M server forms a new MMS message that contains the P2M message 
and sends it to recipients who are on line, and also stores the message in the inbox. 
For recipients who are off-line, the messages would be stored in the P2M servCT 600 
and marked as new (unread) message. 

15 The P2M Ghent 610 executed by the handset 120 registers with P2M Server 

600 when tihe handset 120 is powered on, at which time the new MMS messages are 
deUvered to the handset 120. The P2M Chent 610 receives a notification firom the 
MMSC 606 of the new MMS message, and then retrieves the new MMS message 
firom the MMSC 606. Thereafter, the P2M CUent 610 provides an alert notification to 

20 the user of the new MMS message. The P2M CUent 610 also adds the new MMS 
message to the inbox of the handset 120, and also keeps track of read and unread 
messages. 

Using the new MMS message, the P2M Chent 610 can request dehvery of the 
P2M message stored by the P2M Server 600. Upon receipt of the P2M message, the 
25 P2M CUent 610 plays or displa>^ any audio, video, images, data or text found in the 
P2M message. The P2M message may also be stored on the P2M CUent 610 (even if 
temporarily). 

The P2M CUent 610 provide the necessary fimctionaUty to manage the P2M 
messages, regardless of wh^e they are stored. For example, the P2M CUent 610 may 
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Store a us^ selectable number of P2M messages in the handset 120 itself, and may 
store another user selectable number of P2M messages in the P2M Server 600. 
Further, the user can choose to retrieve, delete, forward or reply to any of the P2M 
messages. 

5 

Message Storage 

This section explains three specific approaches for storing P2M messages. 
In a first approach, the P2M Server 600 would store the P2M message as 
temporary data 612. 

10 In a second approach, the P2M Server 600 would store the P2M message 

using the message storage 614 of the Voice Mail Server 602, wherein standard FTP 
(File Transfer Protocol) coimnands would be used to store and retrieve P2M messages 
fi'om the Voice Mail Server 602. Jn this approach, the P2M Server 600 would store 
each P2M message using a Subscriber Id and Sequence Id. 

15 In a third approach, the P2M Server 600 does not define how the P2M 

message shoidd be stored in the Voice Mail Server 602. Instead, it uses a messaging 
interface with the Voice Mail Server 602, based on the Subscribe Id and Sequence Id. 
The protocol is similar to the FTP commands described above, but the protocol does 
not define where the P2M messages should be stored. The request and response 

20 messages would be the same as the FTP protocol described above. 

FIG. 7 is a diagram that illustrates the call flow for the third approach. 

1. The P2M Server 600 sends a PUT message to the Voice Mail Server 
602, wherein the message includes a Subscriber Id and Sequence Id. 

2. The Voice Mail Server 602 sends a response to tiie P2M Server 600, 
25 acknowledging fhe PUT message. 

3 . The P2M Server 600 transfers a file containing the P2M message to the 
Voice Mail Server 602, and the Voice Mail Server 602 stores the file using the 
Subscriber Id and Sequence Id. 
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4. The P2M Server 600 sends a GET message to the Voice Mail Server 
602, wherein the message includes a Subscriber Id and Sequence Id 

5. The Voice Mail Server 602 sends a response to the P2M Server 600, 
acknowledgmg the GET message. 

5 6. The Voice Mail Server 602 retrieves a file containing the P2M 

message using the Subscriber Id and Sequence Id, and then transfers the file to the 
P2M Server 600. 

7. The P2M Server 600 sends a DELETE message to the Voice Mail 
Server 602, wherein the message includes a Subscriber Id and Sequence Id. 
10 8. The Voice Mail Server 602 deletes a file containing the P2M message 

using the Subscriber Id and Sequence Id, and then sends a response to the P2M Server 
600, acknowledging the DELETE message. 

9. The Voice Mail Server 602 sends a NOTIFY message to the P2M 
Server 600 indicating the Subscriber Id and Calling Party Id. 
15 10. The P2M Server 600 responds to the Voice Mail Server 602 with a 

RESPONSE message with Sequence Id. 

P2M Call Flows 

The following sections describes flie call flows for some of the major 
20 operations in the P2M service. 

P2M Client Sending A P2M Message Using MMS 
FIG. 8 is a diagram that illustrates the call flow for the P2M CU«it 610 
sending a message using MMS according to the preferred embodiment of tite present 
25 invention. 

1 . The user selects a recipient on the handset 120. 

2. The user presses the P2M button on the handset 120. 

3. The P2M Client 610 plays a Start Message tone on the handset 120. 

4. The P2M Client 610 records the P2M message. 
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5. The user releases the P2M button on the handset 120. 

6. The P2M Client 610 displays a menu on ihe handset 120, that indicates 
three options for the user: review, send or re-record. 

7. The user selects eith^ review, send or re-record firom the menu on the 
S handset 120. If review is selected, then the P2M message is played and control 

transfers to #6 above. If re-record is selected, then control transfers to #3 above. If 
send is selected, then control transfers to #8 below. 

8. The P2M Client 610 forms an MMS message (MMl^SUBMTT.REQ) 
with the recipient's information as the text part and the file containing the P2M 

10 message as an attachment. The P2M Client 610 then sends the MMS message to the 
MMSC 606. 

9. The MMSC 606 sends a response (MM1_SUBMIT.RES) message to 
theP2MCUent610. 

Further message processing is described in FIG. 9. 

15 

P2M Server Processing Of The P2M Message 

FIG. 9 is a diagram that illustrates the call flow for the P2M Server 600 
processing the message according to the preferred embodim^t of the present 
invention. 

20 1 . The MMSC 606 sends a deUvery request (MM7_DELIVER.REQ) 

message to the P2M Server 600. 

2, The P2M Server 600 sends a response (MM7_DELIVER.RES) 
message to the MMSC 606. 

3. The P2M Server 600 sends a query message to the RTX 102 to obtain 
25 subscriber, group and recipirat information. At this point, the P2M Server 600 

assigns a muque Message Id to Ihe P2M message, for later reference. A new MMS 
message is formed and then sent to any recipients that are currently online. The new 
MMS message may be locally stored and sent later to recipients that are currently 
ofEline, when they are online again. 
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4. The P2M Server 600 sends a submit request (MM7_SUBMrr.REQ) 
message to the MMSC 606. 

5. The MMSC 606 sends a response (MM7_SUBMmiES) message to 
the P2M Server 600. 

5 6. The MMSC 606 sends a notify request (MMl_NOTIFY.REQ) 

message to the P2M Client 610. The P2M Client 610 uses the Subject field in the 
notify request message to identify the P2M message. 

7, The P2M CUent 610 sends a response 0»4M1_NOTIFY.RES) message 
to the MMSC 606. 

10 8. The MMSC 606 sends a report request (MM7_REPORT.REQ) 

message to the P2M Server 600. 

9. The P2M Server 600 sends a response (MM7_REPORT.RES) message 
to the MMSC 606. 

10. The P2M Client 610 sends a retrieve request (MM1_RETRIEVE.REQ) 
15 message to tiie MMSC 606. The P2M Client 610 retrieves the MMS message 

immediately, and preferably, in the background. 

1 1 . The MMSC 606 sends a response (MM1_R£TRIEVE.R£S) message 
to the P2M Client 610. 

12. Upon completion of the download of the MMS message, the P2M 
20 CUent 610 sends a read reply receipt request 

(MM1_READ_REPLY_RECEIPT.REQ) message to the MMSC 606. 

13. In addition, once the download is completed, the P2M CUent 610 plays 
an Alert New P2M Message tone is played and/or an indication is displayed on the 
handset 120. The user can choose to display or play the P2M message immediately or 

25 at a later time. 

14. The MMSC 606 sends a read reply receipt request 
(MM7_READ_RECEIPT.REQ) message to the P2M Server 600. 

15. The P2M Server 600 sends a response (MM7_READ_RECEIPT.RES) 
message to the MMSC 606. 
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Further message processing is described in FIG. 10. 
P2M Client Retrieving The P2M Message 

FIG. 10 is a diagram that illustrates the call flow for the P2M Server 600 
5 processing the message according to the preferred embodiment of the present 
invention. 

1. The user selects a message for retrieval on the handset 120. 

2. To retrieve a P2M message, the P2M Client 610 sends an SMS 
message containing the details of the P2M message to be retrieved, i.e., the 

10 corresponding Message Id, to the SMSC 604. 

3. The SMSC 604 sends a deliver (SMMP: DELIVER SM) message with 
tiie correq)onding Message Id to the P2M Server 600 via the MMSC 606. Upon 
receipt of the message, the P2M Server 600 retrieves the P2M message using the 
Message Id. 

15 4. The P2M Server 600 sends a submit request (MM7_SUBMIT.REQ) 

message to the MMSC 606. 

5. The MMSC 606 sends a response (MM7_SUBMIT.RES) message to 
the P2M Server 600. 

6. The MMSC 606 sends a notify request (MMl JMOTIFY.REQ) 
20 message to the P2M Client 610 via the SMSC 604. 

7. The P2M Client 610 sends a response (MMlJSrOTIFY.RES) message 
to the MMSC 606 via the SMSC 604. 

8. The MMSC 606 sends a deUvery report request 
(MM7_DELIVERY_REPORT.REQ) message to the P2M Server 600. 

25 9. The P2M Server 600 sends a response 

(MM7_DELIVERY_REPORT.RES) message to the MMSC 606. 

10. The P2M Client 610 sends a retrieve request (MM1_RETRIEVE.REQ) 
message to the MMSC 606 via the SMSC 604. 
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1 1 . The MMSC 606 sends a response ^dMl_RETR]EVE.RES) message 
to the P2M Client 610 via the SMSC 604. 

12. The P2M Client 610 sends a read reply receipt request 
(MM1_READ_REPLYJRECEIPT.REQ) message to the MMSC 606 via the SMSC 
604. 

13. The P2M Client 610 plays an Alert tone (or displays text) and then 
displays or plays the P2M message on the handset 120. 

14. The MMSC 606 sends a read receipt request 
(MM7_READ_RECEIPT.REQ) message to the P2M Server 600. 

15. The P2M Server 600 sends a response (MM7_READ_RECEIPT.RES) 
message to the MMSC 606. 

Further message processing is described in FIG. 1 1 . 

P2M Client Deleting The P2M Message 
15 FIG. 1 1 is a diagram that illustrates the call flow for the P2M Client 610 

deleting the P2M message according to the preferred embodiment of the present 
invention. 

1 . The user selects a P2M message for deletion on the handset 120. 

2. To delete a P2M message, the P2M Client 610 sends an SMS message 
20 containing the details of the P2M message to be deleted, i.e., the corresponding 

Message Id, to the SMSC 604. The P2M message is also deleted locally on the 
handset 120 (if it exists). 

3. The SMSC 604 sends a deliver (SMMP: DELIVER SM) message with 
the corresponding Message Id to the P2M Server 600 via the MMSC 606. Upon 

25 receipt of the message, the P2M Server 600 deletes the P2M message using the 
Message Id. 

4. The P2M Server 600 sends a submit (MM7_STJBMIT SM) message as 
a response to the SMSC 604 via the MMSC 606. 

5. The SMSC 604 sends a confirmation message to the P2M Client 610. 
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Message Inbox Functionality 

The P2M Message Inbox functionality is provided to support management of 
messages as in email. The P2M Client 610 provides functionality to list out previously 
5 received P2M messages for a specified duration (configured in the P2M Server 600 
for tihe subscriber). The P2M Client 610 can store a specified number of P2M 
messages in the handset 120 and tiie remaining messages would be stored in the P2M 
Server 600. The user can play, delete, forward or reply to any of the saved messages. 
Further, the P2M Ghent 610 can download, via MMS, P2M messages stored in the 
10 P2M Server 600 through an SMS request to the P2M Server 600 indicating the 
Message ID (Identification) of the selected message. 

Fragmentation and Reassemblv of Long Messages 

The size of P2M messages conveyed over MMS is limited in size to around 30 
15 Kilobytes, which for voice messages indicates a limit of 40 seconds. Using 

fragmentation and reassembly, longer duration messages can be acconunodated. For 
longer duration messages, the P2M Client 610 divides the message into multiple 
smaller messages to fit within the constraint of MMS. The P2M Server 600 receives 
and sends the firagmented MSS messages to the intended recipients. The terminating 
20 P2M Client 610 would reassemble the fragmented messages and regenerate the 
original long duration message. 

Zero Delay Call Setup 

FIG. 12 depicts the processing at a handset 120 that interfaces to the vdreless 
25 network to provide voice services between a user and one or more destinations, 

wherein call setup for the voice services involves zero delay. Specifically, the user 
starts talking immediately upon initiation of the call setup, the user's speech is 
buffered by tiie handset 120, and the buffered speech is forwarded to the destination 
upon completion of the call setup. 
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The Steps involved are indicated below: 

1 . The user initiates a P2T/P2C session by pressing the P2T/P2C button 
on the handset 120 (or by performing an equivalent operation such as 
choosing a menu item in tiie handset 120). 

5 2. Call setup starts. 

3. The handset 120 generates a confirmation signal, the user starts talking 
immediately upon receiving the confirmation signal, and the handset 
120 buffers the user's speech for a specified duration. The 
confirmation signal may comprise a "chirp," "click," "pop-up 

10 message," etc. Alternatively, the handset 120 may receive an error 

signal if one or more of the destinations is unavailable, or if the ixser if 
the user does not control a floor for group services. The use of such 
signals is optional, not mandatory, and thus tiie signals can be 
employed according to a user preference. 

IS 4. Call setup completes. 

5. When the specified duration expires, the handset 120 stops buffering 
the user's speech and starts its playout of the buffered speech for 
transmission to tiie destination. The specified duration may be 
determined by a user preference, and generally comprises the smaller 

20 of a time period reqxiired to complete the call setup or a tune period 

between the user pressing and releasing a button on the handset 120. 

6. Finally, the user releases the P2T/P2C button on tiie handset 120. The 
above steps apply to the first push of the button only. 

7. Playout of the buffered speech completes. 

25 Although the steps of FIG. 12 illustrate the situation where the specified 

duration is equal to the call setup time, tiiose skilled in the art will recognize that the 
specified duration may be less than the call setup time, for example, when the 
P2T/P2C button is released by the user before call setup completes. 
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Note also that the user may talk for an arbitrary amount of time, but the buffer 
period is limited and, as indicated above, is the smaller of call setup time or the period 
of the first push of the P2T/P2C button. 

As an example, assume that the call setup takes 2 seconds, but the first push of 
5 the P2T/P2C button may be 4 seconds long. In that case, only 2 seconds of speech are 
buffered and playout of those 2 seconds of speech occurs as soon as call setup is 
completed. On the other hand, if the first push of the P2T/P2C button is only 1 .5 
seconds, only 1.5 seconds of speech is buffered, and playout of those 1.5 seconds of 
speech occurs after call setup is completed. In any case, the playout of the buffered 
10 speech starts only after call setup is complete. 

FIGS. 13 and 14 illustrate the call flows for initial call establishment for GSM 
and CDMA P2T or P2C services, respectively, incorporating the zero delay call set- 
up. This solution is equally applicable to other wireless systems such as TDMA and 
evolutions of existing 2G solutions such as 2.5G systems, 3G systems, etc. 
IS FIG. 13 is a diagram that illustrates the call flow for a GSM P2T or P2C call 

according to a preferred embodiment of the present invention. 

1 . The first or originating handset 120 (identified in the figure as handset 
#1) requests an assignment of a dedicated signaling channel for call 
origination, and starts buffering the user's speech. 
20 2. A dedicated signaling channel is assigned and intimated to the first 

handset 120. 

3. A CM Service Request is send to the MSG 104 to initiate a call setup 
procedure. Upon receiving the CM Service Request, the MSG 104 may 
delay the authentication in order to speed up the call setup. 
25 4. The MSG 104 sends a CM Service Accept to the first handset 120 in 

order to proceed with call setup. In this case, authentication may be 
initiated by the MSG 104 at a later time. 
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5. The first haadset 120 sends a setup message with the dialed digits. The 
dialed digits contain the access code for the group call and the group 
ID. 

6. Because the origmation trigger criteria is met as per the subscriber's 
5 profile for P2T/P2C service, the MSG 104 origmates an Initial DP 

(Detection Point) Request to the RTX 102 for further service 
interaction. 

7. After receiving the Initial DP Request firom the MSG 104, the RTX 
102 looks into its database of group information in order to obtain 

10 directory numbers of group members belonging to the group ID 

specified in the message* For each member of the group, the RTX 102 
originates an lAM and sends it to the MSG 104 with a directory 
nimiber as the called party number. The RTX 102 also sends GIG 
information for each terminating leg to the MSG 104. 

15 8. The GSM SGF (Service Gontrol Function) instructs the MSG 1 04 to 

coimect to the RTX 102 by specifying a redirection number. 

9. The MSG 104 triggers the assignment procedure for allocating 
terrestrial resources between the BSC 112 and MSG 104, and radio 
resources for the first handset 120. The first handset 120 is notified 

20 about the allocated channel for this call. 

10. The MSG 104 begins routing the call based on the redirection number 
received firom the GSM SGF. The MSG 104 terminates the call to the 
RTX 102 by sending an lAM. 

1 1 . The RTX 102, after receiving the lAM, immediately responds to the 
25 MSG 104 with an AGM, and subsequently, an ANM with no delay 

between them. 

12. The MSG 104 sends an Alert to the first handset 120 to trigger alerting 
at the first handset 120. 

13. The RTX 102 sends an ANM to the MSG 104. 
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14. The MSG 104 sends a connect to the first handset 120, which stops the 
alerting tone at the first handset 120. 

15. The first handset 120 stops huffering the user's speech, and begins the 
playout of the buffered speech, in order to transmit tiie speech packets 

5 totheRTX102. 

16. The MSG 104 send a paguig request to the BSG 1 12 to locate the 
second or terminating handset 120 (identified in the figure as handset 
#2). 

17. The BSG 1 12 perfomis a paging procedure to locate the second 
10 handset 120. 

18. The second handset 120 requests a dedicated signaling channel. 

19. A dedicated signaling channel is assigned and intimated to the second 
handset 120. 

20. The second handset 120 sends a paging response through the dedicated 
1 S signaling channel. 

21 . When the BSG 1 12 receives the paging response from the second 
handset 120, it sends an MS Gonn Estd (Mobile Station Connection 
Established) message to the MSG 104. 

22. The MSG 104 sends a Setup message to the second handset 120 with 
20 information such as the called party number and group ID. 

23. The second handset 120 responds with a Gall Gonfirmed message to 
the MSG 104. 

24. The MSG 104 perfomis an assignment procedure to allocate terrestrial 
and radio resources. 

25 25. After successfiil allocation of all resources, the second handset 120 

sends an Alerting message to the MSG 104 to indicate that it is 
aloting. 

26. The MSG 104 sends an AGM to the RTX 102 confirming the alerting 
of the temiinating handset 120. 
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27. The second handset 120 (without waitmg for user response) sends a 
Connect message to the MSG 104 if the service does not require the 
user to press any key on the handset 120 to accept the call. This 
provides instant connectivity between the originating and terminating 

5 handsets 120. 

28. The MSG 104 sends an ANM message to the RTX 102 and the RTX 
102 completes the one-way voice path from the originating handset 
120 to terminating handset 120. 

FIG. 14 is a diagram that illustrates the call flow for a GDMA P2T call 
1 0 according to a preferred embodiment of the present invention. 

1 . The first or origmating handset 120 (identified in the figure as handset 
#1) originates a group call, and starts buffering the user's speech. 

2. Upon receivmg the origination request, the MSG 104 analyzes the 
dialed digits and determines that the trigger code in the called party IE 

1 5 meets the origination trigger criteria. On satisfying the origination 

trigger criteria, an ORREQ (Origination Request) message is sent to 
tibie RTX 102. The ORREQ contains the dialed digits. 

3. The MSG 104 begins allocating terrestrial resources required for the 
call between the BSG 1 12 and the MSG 104, and sends GIG (Gircuit 

20 Identity Gode) information in an Assignment request to the BSG 112. 

4. The BSG 112 performs a traffic chaimel setup for the first handset 120, 
which initiates the radio channel allocation procedure. 

5. Meanwhile, the RTX 102 analyzes the dialed digits and identifies the 
group id. It responds to the MSG 104 with an ORREQ message, which 

25 contains the routing number to the RTX 102 so that tiie MSG 104 can 

terminate fliis group call to the RTX 102, 

6. The RTX 102 gets the group id firom the dialed digits received in the 
ORREQ message. It obtains member information including a Mobile 
Directory Number (MDN) firom tiie group database and begins setting 
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up teiminating legs. Based on the MDN, it sends an lAM (Inilial 
Address Message) message to the MSC 104. The terminating legs are 
set-up in parallel with origmating leg set-up to speed up the caU set-up 
time. 

5 7. Subsequent to the first handset 120 acquiring the traffic channel, the 

BSC 112 sends an Assigmnent Complete message to the MSC 104. 
8. The MSC 104 begins to route the call based on routing info 

(TERMLIST) received firom the RTX 102 in the ORREQ message. 
The MSC 104 sends an lAM message to the RTX 102. 

10 9. The RTX 102 after receiving the lAM, immediately responds to the 

MSC 104 with an ACM (Address Complete Message), and 
subsequently ANM (Answer Message) with no delay between them. 
10. The MSC 104 plays an in-band ring back tone after receiving the 
ACM. 

15 11. The ANM is received by the MSC 104 and it stops the ring back tone. 

12. The first handset 120 stops buffering the user's speech, and begins the 
playout of the buffered speech, in order to transmit the speech packets 
to the RTX 102. 

13. The MSC 104 sends a paging request to the BSC 1 12 in order to locate 
20 the second or terminating handset 120 (identified in the figure as 

handset #2). 

14. The BSC 1 12 performs a paging procedure for the second handset 120. 

15. Once a paging response is obtained fi:om the second handset 120, the 
BSC 112 gives a pagmg response to tiie MSC 104. 

25 16. The MSC 104 allocates a terrestrial circuit between the MSC 104 and 

BSC 1 12, and sends the information to the BSC 1 12 in an Assigmnent 
Request. The Assigmnent Request message also contains the calling 
party number with its group ID and signal IE for the alerting second 
handset 120. 
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17. The BSC 1 12 performs a traf&c channel setup procedure for the second 
handset 120, which initiates the radio channel allocation procedure. 

18. Subsequent to completion of the traffic channel setup, the BSC 1 12 
sends an Assignment Complete message to the MSC 104. 

5 19. The BSC 1 12 sends an Alert With Info message to the second handset 

120 to start alerting. This message has the calling party number, which 
contaias the group ID. The second handset 120 understands from this 
group ID that the call is a P2T or P2C, and ignores signal IE in this 
message. 

10 20. The MSC 104 sends an ACM to the RTX 102 after receiving an 

Assignment Complete message from the BSC 1 12, indicating that the 
second handset 120 is alerting. 

21 . The second handset 120 (without waiting for user response) sends a 
connect message to the BSC 1 12 and MSC 104 if the service does not 

15 require the user to press any key on the handset 120 to accept tiie call. 

This provides instant comectivity between the originating and 
terminating handsets 120. 

22. The MSC 104 sends an ANM message to the RTX 102 and the RTX 
102 completes the one-way voice path from the originating handset 

20 120 to the terminating handset 120. 



Conclusion 

The foregoing description of the preferred embodiment of the invention has 
been presented for the purposes of illustration and description. It is not intended to be 
25 exhaustive or to limit tixe invention to the precise fomi disclosed. Many modifications 
and variations are possible in light of the above teaching. It is intended that the scope 
of the invention be limited not with this detailed description, but rather by tiie claims 
appended hereto. 
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